1 / 56

Faz technical challenges 2000 - 2009

Faz.net technical challenges 2000 - 2009. what i won ’t show. business numbers, € business plans. what to do (from the point of view of lowly programmer). invent a business plan define, plan, and implement desired functionality build a robust, secure, scalable system

Download Presentation

Faz technical challenges 2000 - 2009

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Faz.net technical challenges 2000 - 2009

  2. what i won’t show • business numbers, € • business plans

  3. what to do (from the point of view of lowly programmer) • invent a business plan • define, plan, and implement desired functionality • build a robust, secure, scalable system • keep that system up 100% of the time • allow changes to support new business initiatives

  4. a brief history • launched 8 Jan 2001 • “stable” by Spring of 2001 • unstable on 11 Sep 2001 • better able to handle (many classes of) huge load increases by Spring 2002

  5. how big is faz.net? • much smaller than google  • smaller than spiegel

  6. how big is faz.net? • much smaller than google  • smaller than spiegel • comparable to other newspapers

  7. a sketch of our system layout (a couple years old) • load balancer • web servers • DB and file servers • other application servers • client machines, e.g. newsroom • external partners, e.g. freemail provider

  8. an ancient attempt to show how changing an article affects site • editor publishes a new article (or a new version of an existing article) • a DB trigger fires • cached DB result sets get updated • cached HTML gets updated or deleted • (we do things differently now)

  9. how to measure what is happening / whether things are ok • measure throughput at / between various points

  10. (partial) network traffic over time • MRTG (http://oss.oetiker.ch/mrtg/) • Standard, free (Gnu) • Useful at a glance info

  11. how to measure what is happening / whether things are ok • measure throughput at / between various points • measure, e.g. cpu load on web servers (NB: load is pretty low, max would be 12*100)

  12. long term trend: one year

  13. Some errors can be seen by any user with a browser who runs into them • Server error • Wrong contents • Broken HTML, images, or …

  14. some page ailments complain helpfully

  15. digested log files can be helpful • web sites tend to have many log files, several kinds of log files; and some kinds can be *huge* • they tend to be straight ascii files in some format you might have little control over • various kinds of statistics might sometimes interest you • in particular error statistics

  16. ad hoc (logfiles | awk ... excel

  17. ad hoc: mrtg + paint o.ä.

  18. ad hoc

  19. ad hoc: DB query -> Excel

  20. external, hired monitoring service • hire someone outside your site to watch certain pages on your site (load them periodically) and keep statistics about timing, sizes, errors • ideally get regular reports showing everything is groovy • support “drilling” to get more details when necessary

  21. using logarithms to graph events with highly varying scales

  22. some 50x errors showed up on utility servers one day

  23. a primitive top 10 most popular pictures (PIs per hour)

  24. What does this mean? (irregular load distribution, strange peeks)

  25. somewhat subtle: unexpected cpu load spikes on utility machines

  26. diagnosis: software release increases cpu load

  27. Confirmation: rollback helps

  28. a little bit about development methods • requirements gathering (quality varies) • planning • implementation

  29. our implementation languages • browser • html (+ „furniture graphics“) • javascript • css (fairly recently) • public javascript libraries (fairly recently): MooTools, JQuery

  30. One view of a web application pattern (Application Architecture Guide 2.0: Designing Applications on the .NET Platform

  31. our implementation languages • webserver („front end“) • ASP (JScript, mainly 2000 – 2005) • DotNet 2 (2005 – 2007) • DotNet 3 (2007 - )

More Related